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Abstract 

Free theorems are a charm, allowing the derivation of useful state¬ 
ments about programs from their (polymorphic) types alone. We 
show how to reap such theorems not only from polymorphism over 
ordinary types, but also from polymorphism over type constructors 
restricted by class constraints. Our prime application area is that 
of monads, which form the probably most popular type constructor 
class of Haskell. To demonstrate the broader scope, we also deal 
with a transparent way of introducing difference lists into a pro¬ 
gram, endowed with a neat and general correctness proof. 

Categories and Subject Descriptors F.3.1 [Logics and Mean¬ 
ings of Programs]: Specifying and Verifying and Reasoning about 
Programs—Invariants; D.1.1 [Programming Techniques ]: Ap¬ 
plicative (Functional) Programming; D.3.3 [Programming Lan¬ 
guages]: Language Constructs and Features—Polymorphism 

General Terms Languages, Verification 

Keywords relational parametricity 


1. Introduction 

One of the strengths of functional languages like Haskell is an ex¬ 
pressive type system. And yet, some of the benefits this strength 
should hold for reasoning about programs seem not to be re¬ 
alised to full extent. For example, Haskell uses m onads jMoggi| 
1 1991^ to structure programs by separating concerns (Wadler|1992| 
|Liang et al.|1995|> and to safely m ingle pure and impure compu¬ 
tations jPeyton Jones and Wadler||1993| |Launchbury and Peyton| 
Jones 1995). A lot of code can be kept independent of a concrete 
choice of monad. This observation pertains to functions from the 
Prelude (Haskell’s standard library) like 

sequence :: Monad p =$■ [p a] —> p [a], 

but also to many user-defined functions. Such abstraction is cer¬ 
tainly a boon for modularity of programs. But also for reasoning? 
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Let us consider a more specific example, say functions of the 
type Monad p =>- [p Int] —> p Int. Here are someQ 
/i = head 

f 2 ms = sequence ms y>= return o sum 

/3 = /2 o reverse 

fi [ ] = return 0 

U (m : ms) = do i <— m 

let l = length ms 
if i> l then return (i + l) 
else /4 (drop i ms) 

As we see, there is quite a variety of such functions. There can be 
simple selection of one of the monadic computations from the input 
list (as in /i), there can be sequencing of these monadic computa¬ 
tions (in any order) and some action on the encapsulated values (as 
in /2 and fs), and the behaviour, in particular the choice which 
of the computations from the input fist are actually performed, 
can even depend on the encapsulated values themselves (as in /4, 
made a bit artificial here). Further possibilities are that some of the 
monadic computations from the input list are performed repeatedly, 
and so forth. But still, all these functions also have something in 
common. They can only combine whatever monadic computations, 
and associated effects, they encounter in their input fists, but they 
cannot introduce new effects of any concrete monad, not even of 
the one they are actually operating on in a particular application in¬ 
stance. This limitation is determined by the function type. For if an 
f were, on and of its own, to cause any additional effect to happen, 
be it by writing to the output, by introducing additional branching 
in the nondeterminism monad, or whatever, then it would immedi¬ 
ately fail to get the above type parametric over p. In a language like 
Haskell, should not we be able to profit from this kind of abstrac¬ 
tion for reasoning purposes? 

If so, what kind of insights can we hope for? One thing to ex¬ 
pect is that in the special case when the concrete computations in 
an input fist passed to an / :: Monad p => [p Int] —*■ p Int cor¬ 
respond to pure values (e.g., are values of type 10 Int that do not 
perform any actual input or output), then the same should hold of 
f’s result for that input fist. This statement is quite intuitive from 
the above observation about / being unable to cause new effects on 


1 The functions head, sum, reverse, length, and drop are all from the 
Prelude. Their general types and explanation can be found via Hoogle 
( http: //haskell. org/hoogle (. The notation o is for function composi¬ 
tion, while >•>= and do are two different syntaxes for performing compu¬ 
tations in a monad one after the other. Finally, return embeds pure values 
into a monad. 









its own. But what about more interesting statements, for example 
the preservation of certain invariants? Say we pass to / a list of 
stateful computations and we happen to know that they do depend 
on, but do not alter (a certain part of) the state. Is this property pre¬ 
served throughout the evaluation of a given /? Or say the effect en¬ 
capsulated in f’s input list is nondeterminism but we would like to 
simplify the program by restricting the computation to a determin¬ 
istically chosen representative from each nondeterministic mani¬ 
fold. Under what conditions, and for which kind of representative- 
selection functions, is this simplification safe and does not lead to 
problems like a collapse of an erstwhile nonempty manifold to an 
empty one from which no representative can be chosen at all? 

One could go and study these questions for particular functions 
like the /i to f.i given further above. But instead we would like to 
answer them for any function of type Monad [g, Int] —► g Int 
in general, without consulting particular function definitions. And 
we would not like to restrict to the two or three scenarios depicted 
in the previous paragraph. Rather, we want to explore more abstract 
settings of which statements like the ones in question above can be 
seen, and dealt with, as particular instances. And, of course, we pre¬ 
fer a generic methodology that applies equally well to other types 
than the specific one of / considered so far in this introduction. 
These aims are not arbitrary or far-fetched. Precedent has been set 
with the theorems obtained for free by |Wadler| ] 1989| from rela¬ 
tional parametricity i |Reynolds| 1983} . Derivation of such free the¬ 
orems, too, is a methodology that applies not only to a single type, 
works independently of particular function definitions, and applies 
to a diverse range of scenarios: from simple algebraic laws to pow¬ 
erful program transformations ( [Gill et al.|1993}, to me ta-theorems 
about whole classes of algorithms ( |Voigtlander|2008b), to specific 
applications in software engineering and databases jVoigtlander| 
12009 } . 

Unsurprisingly then, we do build on Reynolds’ and Wadler’s 
work. Of course, the framework that is usually considered when 
free theorems are derived needs to be extended to deal with types 
like Monad g => .... But the ideas needed to do so are there for 
the taking. Indeed, both relational parametricity extended for poly¬ 
morphism over type constructors rather than over ordinary types 
only, as well as relational parametricity extended to take class con¬ 
straints into account, are in the folklore. However, these two strands 
of possible extension have not been combined before, and not been 
used as we do. Since we are mostly interested in demonstrating 
the prospects gained from that combination, we refrain here from 
developing the folklore into a full-fledged formal apparatus that 
would stand to blur the intuitive ideas. This is not an overly theoret¬ 
ical paper. Also on purpose, we do not consider Haskell intricacies, 
like those studied by Johann and Voigtlander (2004) and Stenger 
land Voigtlander| ( |2009} , that do affect relational parametricity but 
in a way orthogonal to what is of interest here. Instead, we stay with 
Reynolds’ and Wadler’s simple model (but consider the extension 
to general recursion in Appendix |Cj>. For the sake of accessibility, 
we also stay close to Wadler’s notation. 

2. Free Theorems, in Full Beauty 

So what is the deal with free theorems? Why should it be possible to 
derive statements about a function’s behaviour from its type alone? 
Maybe it is best to start with a concrete example. Consider the type 
signature 

/:' !«]->[«]. 

What does it tell us about the function /? For sure that it takes 
fists as input and produces lists as output. But we also see that / 
is polymorphic, due to the type variable a, and so must work for 
lists over arbitrary element types. How, then, can elements for the 
output fist come into existence? The answer is that the output list 


can only ever contain elements from the input fist. For the function, 
not knowing the element type of the lists it operates over, cannot 
possibly make up new elements of any concrete type to put into 
the output, such as 42 or True, or even id, because then / would 
immediately fail to have the general type [a] —> [a] [^] 

So for any input list l (over any element type) the output fist 
f l consists solely of elements from l. 

But how can / decide which elements from l to propagate to the 
output fist, and in which order and multiplicity? The answer is that 
such decisions can only be made based on the input list l. For in a 
pure functional language / has no access to any global state or other 
context based on which to decide. It cannot, for example, consult 
the user in any way about what to do. And the means by which 
to make decisions based on l are limited as well. In particular, 
decisions cannot possibly depend on any specifics of the elements 
of l. For the function is ignorant of the element type, and so is 
prevented from analysing fist elements in any way (be it by pattern- 
matching, comparison operations, or whatever). In fact, the only 
means for / to drive its decision-making is to inspect the length of l, 
because that is the only element-independent “information content” 
of a list. 

So for any pair of fists l and l' of same length (but possibly 
over different element types) the fists / l and f l' are formed 
by making the same position-wise selections of elements 
from l and l', respectively. 

Now consider the following standard Haskell function: 
map :: (a /3) -> [a] -+ ($J 
map 9 V. = [] 
map g (a : as) = (g a) : (map g as) 

Clearly, map g for any g preserves the lengths of lists. So if 
l' = map g l, then / l and / l' are of the same length and con¬ 
tain, at each position, position-wise exactly corresponding elements 
from l and l', respectively. Since, moreover, any two position-wise 
corresponding elements, one from l and one from l 1 = map g l, 
are related by the latter being the g-image of the former, we have 
that at each position / l 1 contains the g-image of the element at the 
same position in f l. 

So for any fist l and (type-appropriate) function g, we have 
/ (map g l) = map g (f l). 

Note that during the reasoning leading up to that statement we 
did not (need to) consider the actual definition of / at all. The 
methodology of deriving free theorems a la |Wadler|j 1989} is a way 
to obtain statements of this flavour for arbitrary function types, and 
in a more disciplined (and provably sound) manner than the mere 
handwaving performed above. 

The key to doing so is to interpret types as relations. For exam¬ 
ple, given the type signature /::[«]—> [a], we take the type and 
replace every quantification over type variables, including implicit 
quantification (note that the type [a] —> [a], by Haskell convention, 
really means V<x [cc] —> [a]), by quantification over relation vari¬ 
ables: V72. [72] —> [72.]. Then, there is a systematic way of reading 
such expressions over relations as relations themselves. In particu¬ 
lar, 

• base types like Int are read as identity relations, 

• for relations 72 and S, we have 

n^S = {(/, g) | V(a, b) € 72. (/ a,g b) € S}, 


2 The situation is more complicated in the presence of general recursion. 
For further discussion, see Appendix|C| 












• for types r and t' with at most one free variable, say a, and 
a function T on relations such that every relation 72 between 
closed types n and r 2 , denoted 72 : ri <=> t 2 , is mapped to a 
relation T 72 : r[n/a] T'[r 2 /a], we have 

V1Z.T1Z = {(u,t») I Vn, t 3 ,K : n 44 r 2 . (n ni v^) £F7Z} 
(Here, v, T , :: t[ti/q] is the instantiation of u :: Va. r to the 
type n, and similarly for v T2 . In what follows, we will always 
leave type instantiation implicit.) 

Also, every fixed type constructor is read as an appropriate con¬ 
struction on relations. For example, the list type constructor maps 
every relation 72 : n 44 r 2 to the relation [7?.] : [n] 44 [r 2 ] defined 
by (the least fixpoint of) 

m -{([}, [])M(a : as, b: bs ) | (a, b) £ 72, (as, bs) £ [71]} , 
the Maybe type constructor maps every relation 72 : n 44 t 2 to 
the relation Maybe 1Z : Maybe n 44 Maybe r 2 defined by 
Maybe 7?. = {(Nothing, Nothing)} U 

{(Just a, Just b) | (a, b) £11 }, 
and similarly for other user-definable types. 

The key insight of relational parametricity a la |Reynolds| ( |1983| > 
now is that any expression over relations that can be built as above, 
by interpreting a closed type, denotes the identity relation on that 
type. 

For the above example, this insight means that any / :: 
Va. [a] —> [a] satisfies (/,/) £ VIZ. [1Z] —+ [72.], which by 
unfolding some of the above definitions is equivalent to having for 
every n, r 2 , 1Z : n 44 r 2 , l :: [n], and l' :: [r 2 ] that (Z, Z') £ [72] 
implies (/ l, f l') £ [72], or, specialised to the function level 
C 1Z i—> g, and thus [72] i—» map g), for every g :: n —> r 2 
and Z :: [n] that f (map g l) = map g (f l). This proof fi¬ 
nally provides the formal counterpart to the intuitive reasoning 
earlier in this section. And the development is algorithmic enough 
that it can be performed automatically. Indeed, an online free the¬ 
orems generator (|Bbhme||2007f is accessible at our homepage 
(http: //linux. tcs. inf . tu-dresden. de/~voigt/ft/). 

3. The Extension to Type Constructor Classes 

We now want to deal with two new aspects: with quantification over 
type constructor variables (rather than just over type variables) and 
with class constraints ( |Wadler and Blott|1989| >. For both aspects, 
the required extensions to the interpretation of types as relations 
appear to be folklore, but have seldom been spelled out and have 
not been put to use before as we do in this paper. 

Regarding quantification over type constructor variables, the 
necessary adaptation is as follows. Just as free type variables are in¬ 
terpreted as relations between arbitrarily chosen closed types (and 
then quantified over via relation variables), free type constructor 
variables are interpreted as functions on such relations tied to ar¬ 
bitrarily chosen type constructors. Formally, let ki and rt 2 be type 
constructors (of kind *—>*). A relational action for them, denoted 
T \ k i 44 /c 2 , is a function T on relations between closed types 
such that every 1Z : n 44 r 2 (for arbitrary n and t 2 ) is mapped to 
an T 1Z : Ki ti 44 k 2 t 2 . For example, the function T that maps 
every TZ : t\ 44 t 2 to 

T1Z = {(Nothing, [])} U 

{(Just a, b : bs) \ (a, b) £ 1Z, bs :: [r 2 ]} 
is a relational action T : Maybe 44 []. The relational interpreta¬ 
tion of a type quantifying over a type constructor variable is now 
performed in an analogous way as explained for quantification over 
type (and then, relation) variables above. In different formulations 
and detail, the same basic idea is mentioned or used by |Fegaras and| 


Sheard (1996), Kucan (19971, Takeuti (20011, and Vytiniotis and 
|Weirich|l|2009k 

Regarding class constraints, |Wadler] j 1989| Section 3.4) directs 
the way by explaining how to treat the type class Eq in the context 
of deriving free theorems. The idea is to simply restrict the relations 
chosen as interpretation for type variables that are subject to a class 
constraint. Clearly, only relations between types that are instances 
of the class under consideration are allowed. Further restrictions 
are obtained from the respective class declaration. Namely, the 
restrictions must precisely ensure that every class method (seen as 
a new constant in the language) is related to itself by the relational 
interpretation of its type. This relatedness then guarantees that the 
overall result (i.e., that the relational interpretation of every closed 
type is an identity relation) stays intact ( |Mitchell and Meyer| 1985[ . 
The same approach immediately applies to type constructor classes 
as well. Consider, for example, the Monad class declaration: 
class Monad p where 
return :: a —> pa 
(»=) :: p a —* (a p /3) —* p {3 

Since the type of return is Vp. Monad p (Va. a —> p a), 
we expect that (return, return ) £ VZF. Monad T =► (VIZ. 1Z —> 
T 1Z), and similarly for »=. The constraint “Monad T” on a 
relational action is now defined in precisely such a way that both 
conditions will be fulfilled. 

Definition 1. Let ki and «: 2 be type constructors that are instances 
of Monad and let T \ k i k 2 be a relational action. If 

• (retum K1 , retum K2 ) £ VIZ. 72. —> IF 1Z and 
. ((»= K1 ), (»= K2 )) € VIZ. VS.F1Z-> ((1Z -► FS) -v 
TS), 

then T is called a Monad -achon[j( While we have decided to gen¬ 
erally leave type instantiation implicit, we explicitly retain instan¬ 
tiation of type constructors in what follows, except for some exam¬ 
ples.) 

For example, given the following standard Monad instance defini- 

instance Monad Maybe where 

return a = Just a 
Nothing >5>= k = Nothing 
Just a »= k = k a 

instance Monad [] where 

return a = [a] 

as >»>= k = concat (map k as) 
the relational action T : Maybe <=> [] given above is not a Monad- 
action, because it is not the case that ((>i>=Maybe), (»=[])) £ 
VIZ. VS. TlZ^t ((1Z —> T S) —> T S). To see this, consider 

TZ = S = (dint , 
mi = Just 1, 
m 2 = [1,2], 

ki = Xi —> if i > 1 then Just i else Nothing , and 

fc 2 = \i —> reverse [2..*]. 

Clearly, (mi, m2) £ T id\ nt and (fci, fc 2 ) £ (dint —> ZF id\ n t, but 
(mi »=Maybe fci, m 2 »=[] k 2 ) = (Nothing, [2]) ^ T id\„ t . On 
the other hand, the relational action T’ : Maybe O [] with 

T’ 1Z = {(Nothing,!])} U {(Just a, [6]) | (a, b) £lZ} 
is a Monad-action. 

3 It is worth noting that “dictionary translation” jwadler and Blott| 1989^ 
would be an alternative way of motivating this definition. 
















We are now ready to derive free theorems involving (poly¬ 
morphism over) type constructor classes. For example, functions 
/ :: Monad n a#* ,|]u Int] —> p, Int as considered in the introduc¬ 
tion will necessarily always satisfy (/, /) 6 V.F. Monad T => 
[J- idint] —*• T irfint, i.e., for every choice of type constructors 
Ki and K'i that are instances of Monad, and every Monad-action 
T \ K\ k 2 , we have (f K1 ,f K2 ) € [F id\ nt ] —> T idi nt . In the 
next section we prove several theorems by instantiating the F here, 
and provide plenty of examples of interesting results obtained for 
concrete monads. 

An important role will be played by a notion connecting differ¬ 
ent Monad instances on a functional, rather than relational, level. 

Definition 2. Let and K2 be instances of Monad and let h :: 

Ki a —* K2 a. If 

• ho return K1 = return K2 and 

• for every choice of closed types r and r\ m :: Ki r, and 
k :: r —> Ki t', 

h (m ^5>= K1 k) =hm >>>= K2 h o k, 

then h is called a Monad -morphism. 

The two notions of Monad-action and Monad-morphism are 
strongly related, in that Monad-actions are closed under point- 
wise composition with Monad-morphisms or the inverses thereof, 
depending on whether the composition is from the left or from the 
right ( |Filinski and St0vring|2OO7| Proposition 3.7(2)). 

4. One Application Field: Reasoning about 
Monadic Programs 

For most of this section, we focus on functions f :: Monad // => 
[p Int] —► p Int. However, it should be emphasised that results 
of the same spirit can be systematically obtained for other func¬ 
tion types involving quantification over Monad-restricted type con¬ 
structor variables just as well. And note that the presence of the 
concrete type Int in the function signature makes any results we ob¬ 
tain for such / more, rather than less, interesting. For clearly there 
are strictly, and considerably, fewer functions of type Monad p =>• 
[/z ct] —> /x a than there are of type Monad p => [p Int] —> p lnt|^] 
so proving a statement for all functions of the latter type demon¬ 
strates much more power than proving the same statement for all 
functions of the former type only. In other words, telling / what 
type of values are encapsulated in its monadic inputs and output 
entails more possible behaviours of / that our reasoning principle 
has to keep under control. 

Also, it is not the case that using Int in most examples in this 
section means that we might as well have monomorphised the 
monad interface as follows: 

class IntMonad p where 

return :: Int —> p 

(»=) :: p —► (Int -»• p) -*• p 

and thus are actually just proving results about a less interesting 
type IntMonad p => [p] —> p without any higher-orderedness 
(viz., quantifying only over a type variable rather than over a type 
constructor variable). This impression would be a misconception, 
as we do indeed prove results for functions critically depending 
on the use of higher-order polymorphism. That the type under 
consideration is Monad p =£- [p Int] —> p Int does by no way 
mean that monadic encapsulation is restricted to only integer values 


4 After all, any function (definition) of the type polymorphic over a can also 
be given the more specific type, whereas of the functions /i to fi given in 
the introduction as examples for functions of the latter type only /i can be 
given the former type as well. 


inside functions of that type. Just consider the function /2 from the 
introduction. During that function’s computation, the monadic bind 
operation (»=) is used to combine a p-encapsulated integer list 
(viz., sequence ms :: p [Int]) with a function to a p-encapsulated 
single integer (viz., return o sum :: [Int] —> p Int). Clearly, the 
same or similarly modular code could not have been written at 
type h IntMonad p =>- [p] —> p, because there is no way 
to provide a function like sequence for the IntMonad class (or 
any single monomorphised class), not even when we are content 
with making sequence less flexible by fixing the a in its current 
type to be Int. So again, proving results about all functions of type 
/ :: Monad p =>■ [p Int] —> p Int covers more ground than might 
at first appear to be the case. 

Having rationalised our choice of example function type, let us 
now get some actual work done. As a final preparation, we need to 
mention three laws that Monad instances k are often expected to 
satisfy]^] 

return K a >>>=« k = ka (1) 

m y>= K retum K = m (2) 

(m y>=K k ) y>= K q = m »=« (A a —> ka ~^>= K q) (3) 

Since Haskell does not enforce these laws, and it is easy to define 
Monad instances violating them, we will explicitly keep track of 
where the laws are required in our statements and proofs. 

4.1 Purity Preservation 

As mentioned in the introduction, one first intuitive statement we 
naturally expect to hold of any / :: Monad p => [p Int] —> p Int 
is that when all the monadic values supplied to / in the input list 
are actually pure (not associated with any proper monadic effect), 
then /’s result value, though of some monadic type, should also be 
pure. After all, / itself, being polymorphic over p, cannot introduce 
effects from any specific monad. This statement is expected to hold 
no matter what monad the input values live in. For example, if 
the input list consists of computations in the fist monad, defined 
in the previous section and modelling nondeterminism, but all 
the concretely passed values actually correspond to deterministic 
computations, then we expect that /’s result value also corresponds 
to a deterministic computation. Similarly, if the input list consists 
of 10 computations, but we only pass ones that happen to have no 
side-effect at all, then /’s result, though living in the 10 monad, 
should also be side-effect-free. To capture the notion of “purity” 
independently of any concrete monad, we use the convention that 
the pure computations in any monad are those that may be the result 
of a call to return. Note that this does not mean that the values in 
the input list must syntactically be return-calls. Rather, each of 
them only needs to be semantically equivalent to some such call. 
The desired statement is now formalised as follows. It is proved in 
Appendix [A] and is a corollary of Theorem[3](to be given later). 


Theorem 1 . Let f :: Monad /z =>■ [/j, Int] —> /z Int, let k be 
an instance of Monad satisfying law |7J, and let l :: [k Int]. 
If every element in l is a retum K -image, then so is f K l. 


We can now reason for specific monads as follows. 


Example 1 . Let l :: [[Int]], i.e., I :: [re Int] for k = []. We 
might be interested in establishing that when every element 


5 Indeed, only a Monad instance satisfying these laws constitutes a 
“monad” in the mathematical sense of the word. 








in l is (evaluated to) a singleton list, then the result of applying 
any f :: Monad p => [p Int] —> p Int to l will be a singleton 
list as well. While this propagation is easy to see for /i, f%, 
and /3 from the introduction, it is maybe not so immediately 
obvious for the /4 given there. However, Theorem [T] tells us 
without any further effort that the statement in question does 
indeed hold for /4, and for any other / of the same type. 


Likewise, we obtain the statement about side-effect-free computa¬ 
tions in the 10 monad envisaged above. All we rely on then is that 
the 10 monad, like the list monad, satisfies monad law |lj. 

4.2 Safe Value Extraction 

A second general statement we are interested in is to deal with 
the case that the monadic computations provided as input are not 
necessarily pure, but we have a way of discarding the monadic 
layer and recovering underlying values. Somewhat in the spirit of 
unsafePerformlO :: 10 a —> a, but for other monads and hope¬ 
fully safe. Then, if we are interested only in a thus projected result 
value of /, can we show that it only depends on likewise projected 
input values, i.e., that we can discard any effects from the monadic 
computations in /’s input list when we are not interested in the 
effectful part of the output computation? Clearly, it would be too 
much to expect this reduction to work for arbitrary “projections”, 
or even arbitrary monads. Rather, we need to devise appropriate re¬ 
strictions and prove that they suffice. The formal statement is as fol- 


Theorem 2. Let f :: Monad p [p Int] —> p Int, let k be 
an instance of Monad, and let p :: k a —> a. If 

• p o return „ = id and 

• for every choice of closed types r and t' , m :: k t, and 

k :: T —> kt\ 

p (m »= K k)=p(k (p m )), 
then p o /,. gives the same result for any two lists of 
same length whose corresponding elements have the same p- 
images, i.e., p o f K can be “factored" as g o (map p) for 
some suitable g :: [Int] —> Intjj 


The theorem is proved in Appendix [B] Also, it is a corollary of 
Theorem[4] Note that no monad laws at all are needed in Theorem[2] 
and its proof. The same will be true for the other theorems we 
are going to provide, except for Theorem [5] But first, we consider 
several example applications of Theorem [5] 


Example 2. Consider the well-known writer, o 
monad (specialised here to the String monoid): 

r logging, 

newtype Writer a = Writer (a, String) 


instance Monad Writer where 

return a = Writer (a, “”) 

Writer (a, s) >>= k = 

Writer (case k a of Writer (a', s') —> (a', 

S + a')) 


6 In fact, this g is explicitly given as follows: unld o /y o (map Id), using 
the type constructor Id and its Monad instance definition from Appendix|A| 


Assume we are interested in applying an / :: Monad p =4> 
[jU Int] —> p Int to an I. :: [Writer Int], yielding a monadic 
result of type Writer Int. Assume further that for some partic¬ 
ular purpose during reasoning about the overall program, we 
are only interested in the actual integer value encapsulated in 
that result, as extracted by the following function: 
p :: Writer a —> a 
p (Writer (o, s)) = a 

Intuition suggests that then the value of p (/ l) should not 
depend on any logging activity of elements in l. That is, if l 
were replaced by another l 1 :: [Writer Int] encapsulating the 
same integer values, but potentially attached with different 
logging information, then p (/ l') should give exactly the 
same value. Since the given p fulfils the required conditions, 
Theorem[2]confirms this intuition. 


It should also be instructive here to consider a negative example. 


Example 3. Recall the list monad defined in Section [3] It is 
tempting to use head :: [cr] —> a as an extraction function 
and expect that for every / :: Monad p =>■ [p Int] —> p Int, 
we can factor head o f as g o ( map head ) for some suitable 
g :: [Int] —> Int. But actually this factorisation fails in a subtle 
way. Consider, for example, the (for the sake of simplicity, 
artificial) function 
fs :: Monad p =>■ [p Int] —> p Int 
fs [ ] = return 0 

h (m : ms) = do i <— m 

f 5 (if i > 0 then ms else tail ms) 

Then for l = [[1], []] and l' = [[1,0], []], both of type [[Int]], 
we have map head l = map head l', but head (/s l) ^ 
head (/g l'). In fact, the left-hand side of this inequation 
leads to an “head of empty list”-error, whereas the right- 
hand side delivers the value 0. Clearly, this means that the 
supposed g cannot exist for /g and head. An explanation for 
the observed failure is provided by the conditions imposed on 
p in Theorem [2] It is simply not true that for every m and k, 
head ( m '»= k) = head ( k ( head m)). More concretely, 
the failure for /r, observed above arises from this equation 
being violated for m = [1,0] and k = Xi —> if i > 
0 then [] else [0]. 


Since the previous (counter-)example is a bit peculiar in its reliance 
on runtime errors, let us consider a related setting without empty 
lists, an example also serving to further emphasise the predictive 
power of the conditions on p in Theorem[2] 


Example 4. Assume, just for the scope of this example, that 
the type constructor [] yields (the types of) nonempty lists 
only. Clearly, it becomes an instance of Monad by just the 
same definition as given in Section [3] There are now several 
choices for a never failing extraction function p :: [a] —> a. 
For example, p could be head, could be last, or could be 
the function that always returns the element in the middle 
position of its input list (and, say, the left one of the two 
middle elements in the case of a list of even length). But which 
of these candidates are “good” in the sense of providing, for 









every / :: Monad p =$■ [p Int] —> p Int, a factorisation of 
p o / into g o (map p) ? 

The answer is provided by the two conditions on p in 
Theorem [2] which specialised to the (nonempty) list monad 
require that 

• for every a, p [a] = a, and 

• for every choice of closed types t and t' , m :: [r], and 
k :: r —> jjr *]!,p ( concat (map k m)) = p(k(p m)). 

From these conditions it is easy to see that now p = head 
is good (in contrast to the situation in Example [3}, and so is 
p = last, while the proposed “middle extractor” is not. It 
does not fulfil the second condition above, roughly because 
k does not necessarily map all its inputs to equally long 
lists. (A concrete counterexample fe, of appropriate type, can 
easily be produced from this observation.) 


4.3 Monad Subspacing 

Next, we would like to tackle reasoning not about the complete 
absence of (a la Theorem [TJ, or disregard for (a la Theorem [2j, 
monadic effects, but about finer nuances. Often, we know cer¬ 
tain computations to realise only some of the potential effects to 
which they would be entitled according to the monad they live 
in. If, for example, the effect under consideration is nondetermin¬ 
ism a la the standard list monad, then we might know of some 
computations in that monad that they realise only none-or-one- 
nondeterminism, i.e., never produce more than one answer, but may 
produce none at all. Or we might know that they realise only non- 
failing-nondeterminism, i.e., always produce at least one answer, 
but may produce more than one. Then, we might want to argue that 
the respective nature of nondeterminism is preserved when com¬ 
bining such computations using, say, a function / :: Monad p => 
[p Int] —> p Int. This preservation would mean that applying any 
such / to any list of empty-or-singleton lists always gives an empty- 
or-singleton list as result, and that applying any such f to any list 
of nonempty lists only gives a nonempty list as result for sure. Or, 
in the case of an exception monad (Either String), we might want 
to establish that an application of / cannot possibly lead to any ex¬ 
ceptional value (error description string) other than those already 
present somewhere in its input list. Such “invariants” can often be 
captured by identifying a certain “subspace” of the monadic type 
in question that forms itself a monad, or, indeed, by “embedding” 
another, “smaller”, monad into the one of interest. Formal counter¬ 
parts of the intuition behind the previous sentence and the vague 
phrases occurring therein can be found in Definition [2] and the fol¬ 
lowing theorem, as well as in the subsequent examples. 


Theorem 3. Let / :: Monad p =$- \ji Int] —> p Int, let 
h :: K\ a —> k 2 a be a Monad-morphism, and let l :: [n 2 Int], 
If every element in l is an h-image, then so is f K2 l. 


Proof. We prove that for every l' :: [ki Int], 

f K2 (map hi') = h (f K1 l') . (4) 

To do so, we first show that F : n 2 43- Ki with 
F TZ = (k 2 TZ) ; h _1 , 

where is (forward) relation composition and ,c_1 ” gives the 
inverse of a function graph, is a Monad-action. Indeed, 


• (return K21 return K1 ) € V7 Z. TZ ^ F TZ, since for ev¬ 
ery TZ and (a, b) €. 7Z, ( return K2 a, h (retum K1 b )) = 
( return « 2 a, retum K2 b) €. k 2 TZ by ( return ^, return K2 ) €. 
MTZ. TZ n 2 TZ (which holds due to return K2 :: Vcr. a —> 
n 2 a), and 

• ((»=«2),(»=«i)) e V7?.. VS. FTZ -► ((TZ -► FS) -> 
F S), since for every TZ, S, (mi,m 2 ) € (k 2 TZ) ; ft, -1 , and 

(fci.te) eTZ^ ((k 2 S) ; /r 1 ), 

(mi ^5 >=k 2 ki,h (m 2 »= K1 k 2 )) = 

(mi ^5>=k 2 ki, h m 2 5i>=k 2 h o k 2 ) £ n 2 S 
by ((»= K2 ),(»= K2 )) 6 VK. VS. k 2 TZ —► ((TZ -► 
k 2 S) —► k 2 S), (mi,h m 2 ) 6 n 2 TZ, and (ki,h o k 2 ) £ 
TZ —y k 2 S. 

Hence, (/ re2 ,/ rei ) 6 [F idi„t] —> F idi„ t . Given that we have 
F (dint = (k 2 idint) ; h ~ 1 = h ~ 1 , this implies the claim. (Note 
that k 2 id\ nt is the relational interpretation of the closed type k 2 Int, 
and thus itself denotes id K2 i„t.) 

Using Theorem [3] we can indeed prove the statements mentioned 
for the list and exception monads above. Here, for diversion, we 
instead prove some results about more stateful computations. 


Example 5. Consider the well-known reader monad: 
newtype Reader p a = Reader (p —^ a) 

instance Monad (Reader p) where 

return a = Reader (Xr —> a) 

Reader g ^>= k = 

Reader (Xr —> case k (g r) of Reader g' — > g' r) 
Assume we are given a list of computations in a Reader 
monad, but it happens that all present computations depend 
only on a certain part of the environment type. For example, 
for some closed types n andr2,Z :: [Reader (ti,t 2 ) Int],and 
for every element Reader g ini, g (x, y) never depends on y. 
We come to expect that the same kind of independence should 
then hold for the result of applying any / :: Monad p =4> 
\p Int] —> p Int to l. And indeed it does hold by Theorem[3] 
with the following Monad-morphism: 

h :: Reader t\ a —> Reader (n, r 2 ) a 
h (Reader g) = Reader (g o fst) 


It is also possible to connect more different monads, even involving 
the 10 monad. 


Example 6. Let l :: [10 Int] and assume that the only side- 
effects that elements in l have consist of writing strings to the 
output. We would like to use Theorem[3]to argue that the same 
is then true for the result of applying any / :: Monad p => 
.[jit Int] — > p, Int to l. To this end, we need to somehow 
capture the concept of “writing (potentially empty) strings to 
the output as only side-effect of an 10 computation” via an 
embedding from another monad. Quite naturally, we reuse the 
Writer monad from Example[2] The embedding function is as 
follows: 

h :: Writer a —> 10 a 

h (Writer (a, s)) = putStr s return a 
What is left to do is to show that h is a Monad-morphism. 
But this property follows from putStr = return (), 






putStr (s -H- s') = putStr s >s> putStr s', and monad 
laws {7} and for the 10 monad. 


Similarly to the above, it would also be possible to show that when 
the 10 computations in l do only read from the input (via, possibly 
repeated, calls to getChar), then the same is true of / l. Instead of 
exercising this through, we turn to general state transformers. 


Example 7. Consider the well-known state monad: 
newtype State a a = State (a —> (a, cr)) 

instance Monad (State a) where 
return a = State (As —*■ (a, s)) 

State g »= k = 

State (As —> let (a, s’) = g s in 

case k a of State g' —> g' s') 
Intuitively, this monad extends the reader monad by not only 
allowing a computation to depend on an input state, but also to 
transform the state to be passed to a subsequent computation. 
A natural question now is whether being a specific state trans¬ 
former that actually corresponds to a read-only computation 
is an invariant that is preserved when computations are com¬ 
bined. That is, given some closed type t and l :: [State r Int] 
such that for every element State g in l, snd o g = id, is it 
the case that for every / :: Monad p =£- [p Int] —► p Int, also 
/ l is of the form State g for some g with snd o g = id ? 

The positive answer is provided by Theorem [3] with the 
following Monad-morphism: 

h :: Reader t a —> State r a 
h (Reader g) = State (As —> (g s, s)) 


Similarly to the above, we can show preservation of the invariant 
that a computation transforms the state “in the background”, while 
the primary result value is independent of the input state. That 
is, if for every element State g in l, there exists an i :: Int 
with fst o g = const i, then the same applies to / l. It should 
also be possible to transfer the above kind of reasoning to the ST 
monad (Launchbury and Peyton Jones| 1995} . 

4.4 Effect Abstraction 

As a final statement about our pet type, Monad p =$■ [p Int] —> 
p Int, we would like to show that we can abstract from some aspects 
of the effectful computations in the input list if we are interested 
in the effects of the final result only up to the same abstraction. 
For conveying between the full effect space and its abstraction, we 
again use Monad-morphisms. 


Theorem 4. Let f :: Monad p =>■ [p Int] —> p Int and let 
h :: Ki a —y K2 a be a Monad -morphism. Then h o f K1 
gives the same result for any two lists of same length whose 
corresponding elements have the same h-images. 


Proof. Let li,h :: [ki Int] be such that maph L = map h h- 
Then h (/„., l\) = h (f K1 h) by statement <(4j from the proof of 
Theorem[3] 


Example 8. Consider the well-known exception monad: 
instance Monad (Either String) where 

return a = Right a 
Left err >£>= k = Left err 
Right a k = ka 

We would like to argue that if we are only interested in 
whether the result of / for some input list over the type 
Either String Int is an exceptional value or not (and which 
ordinary value is encapsulated in the latter case), but do not 
care what the concrete error description string is in the for¬ 
mer case, then the answer is independent of the concrete error 
description strings potentially appearing in the input list. For¬ 
mally, let h,h :: [Either String Int] be of same length, and 
let corresponding elements either be both tagged with Left 
(but not necessarily containing the same strings) or be iden¬ 
tical Right-tagged values. Then for every / :: Monad p => 
[p Int] —> p Int, / h and f 1.2 either are both tagged with Left 
or are identical Right-tagged values. This statement holds by 
Theorem [4] with the following Monad-morphism: 

h :: Either String a —> Maybe a 
h (Left err) = Nothing 
h (Right a) = Just a 


4.5 A More Polymorphic Example 

Just to reinforce that our approach is not specific to our pet type 
alone, we end this section by giving a theorem obtained for another 
type, the one of sequence from the introduction, also showing 
that mixed quantification over both type constructor variables and 
ordinary type variables can very well be handled. The theorem’s 
statement involves the following function: 

fmap :: Monad p=> (a —* 0) —> pa —> p fi 
fmap g m = m X>= return o g 


Theorems. Let f :: Monad p =► [p a] —► p [a] and let 
h :: Ki a —► K2 a be a Monad -morphism. If k 2 satisfies 
law |2]i, then for every choice of closed types n and 72 and 
g :: Ti -> 7*2, 

f K2 o map (fmap K2 g) o map h 
fmap K2 (map g) o h o f K1 0 


Intuitively, this theorem means that any / of type Monad p 
\p a] —> p [a] commutes with, both, transformations on the monad 
structure and transformations on the element level. The occurrences 
of map and fmap are solely there to bring those transformations h 
and g into the proper positions with respect to the different nestings 
of the type constructors p and [] on the input and output sides of /. 
Note that by setting either g or h to id, we obtain the specialised 
versions 

f K2 o map h = h o f K1 


7 For the curious reader: the proof derives this statement from (/ K2 , f K1 ) 6 
[T g -1 ] —> T [g _1 ] for the same Monad-action T : K2 43- ki as used in 
the proof of Theorem|3] 












f K o map ( fmap K g) = fmap K (map g) o f K . (5) 

Further specialising the latter by choosing the identity monad for k, 
we would also essentially recover the free theorem derived for 
/::[«]-► [a] in Section|| 

5. Another Application: Difference Lists, 
Transparently 

It is a well-known problem that computations over lists sometimes 
suffer from a quadratic runtime blow-up due to left-associatively 
nested appends. For example, this is so for flattening a tree of type 
data Tree a = Leaf a | Node (Tree a) (Tree a) 
using the following function: 

flatten :: Tree a —> [a] 
flatten (Leaf a) = [a] 
flatten (Node ti t2 ) = flatten ti -H- flatten t2 
An equally well-known solution is to switch to an alternative rep¬ 
resentation of lists as functions, by abstraction o ver the l i st end , 
often called difference lists. In the formulation of |Hughes| ( |1986) , 
but encapsulated as an explicitly new data type: 

newtype DList a = DL {unDL :: [a] —> [cr]} 

rep :: [a] —> DList a 
rep l = DL (l -H-) 

abs :: DList a —* [a] 
abs (DL /) = /[] 

emptyR :: DList a 
emptyR = DL id 

consR :: a —> DList a —► DList a 
consR a (DL /) = DL ((a :) o /) 

appendR :: DList a —> DList a —> DList a 
appendR (DL /) (DL g) = DL (/ o g) 

Then, flattening a tree into a list in the new representation can be 
done using the following function: 
flatten' :: Tree a —> DList a 
flatten' (Leaf a) = consR a emptyR 
flatten' (Node ti t2) = appendR ( flatten' ti) ( flatten' t2 ) 
and a more efficient variant of the original function, with its original 
type, can be recovered as follows: 

flatten :: Tree a —► [a] 
flatten = abs o flatten' 

There are two problems with this approach. One is correctness. 
How do we know that the new flatten is equivalent to the original 
one? We could try to argue by “distributing” abs over the definition 
of flatten 1 , using abs emptyR = [], abs ( consR a as) = 
a : abs as, and 

abs (appendR as bs) = abs as -H- abs bs . (6) 

But actually the last equation does not hold in general. The rea¬ 
son is that there are as :: DList r that are not in the image of 
rep. Consider, for example, as = DL reverse. Then neither is 
as = rep l for any l, nor does (61 hold for every bs. Any argu¬ 
ment “by distributing abs” wouldthus have to rely on the implicit 
assumption that a certain discipline has been exercised when going 
from the original flatten to flatten' by replacing [], (:), and (-H-) 


by emptyR, consR, and appendR (and/or applying rep to explicit 
lists). But this implicit assumption is not immediately in reach for 
formal grasp. So it would be nice to be able to provide a single, 
conclusive correctness statement for transformations like the one 
above. One way to do so was presented by | Voigtlander| (2002) , but 
it requires a certain restructuring of code that can hamper composi- 
tionality and flexibility by introducing abstraction at fixed program 
points (via lambda-abstraction and so-called uams/i-combinators). 
This also brings us to the second problem with the simple approach 

When, and how, should we switch between the original and the 
alternative representations of lists during program construction? If 
we first write the original version of flatten and only later, after 
observing a quadratic runtime overhead, switch manually to the 
flatten'-version, then this rewriting is quite cumbersome, in par¬ 
ticular when it has to be done repeatedly for different functions. 
Of course, we could decide to always use emptyR, consR, and 
appendR from the beginning, to be on the safe side. But actually 
this strategy is not so safe, efficiency-wise, because the representa¬ 
tion of lists by functions carries its own (constant-factor) overhead. 
If a function does not use appends in a harmful way, then we do 
not want to pay this price. Hence, using the alternative presentation 
in a particular situation should be a conscious decision, not a de¬ 
fault. And assume that later on we change the behaviour of flatten, 
say, to explore only a single path through the input tree, so that no 
appends at all arise. Certainly, we do not want to have to go and 
manually switch back to the, now sufficient, original list represen- 

The cure to our woes here is almost obvious, and has often been 
applied in similar situations: simply use overloading. Specifically, 
we can declare a type constructor class as follows: 
class ListLike 8 where 
empty :: <5 a 
cons :: a -f <5 a -f <5 a 
append : : 8 a —> 5 a —> 5 a 
and code flatten in the following form: 

flatten :: Tree a —> (V<5. ListLike 8 => 8 a) 
flatten (Leaf a) = cons a empty 
flatten (Node ti t2) = append (flatten ti) (flatten t2) 
Then, with the obvious instance definitions 

instance ListLike [] where 
empty = [] 
cons = (:) 
append = (-H-) 

instance ListLike DList where 

empty = emptyR 
cons = consR 
append = appendR 

we can use the single version of flatten above both to produce 
ordinary lists and to produce difference lists. The choice between 
the two will be made automatically by the type checker, depending 
on the context in which a call to flatten occurs. For example, in 

last (flatten t) (7) 

the ordinary list representation will be used, due to the input type 
of last. Actually, ijTJi will compile (under GHC, at least) to ex¬ 
actly the same code as last (flatten t) for the original definition 
of flatten from the very beginning of this section. Any overhead 
related to the type class abstraction is simply eliminated by a stan¬ 
dard optimisation. In particular, this means that where the original 
representation of lists would have perfectly sufficed, programming 
against the abstract interface provided by the ListLike class does 




no harm either. On the other hand, {7} of course still suffers from 
the same quadratic runtime blow-up as with the original definition 
of flatten. But now we can switch to the better behaved difference 
list representation without touching the code of flatten at all, by 
simply using 

last (abs (flatten t)) . (8) 

Here the (input) type of abs determines flatten to use emptyR, 
consR, and appendR, leading to linear runtime. 

Can we now also answer the correctness question more satis¬ 
factorily? Given the forms of l[7} and {8}, it is tempting to simply 
conjecture that abs t = t for any t. But this conjecture cannot be 
quite right, as abs has different input and output types. Also, we 
have already observed that some t of abs’ s input type are prob¬ 
lematic by not corresponding to any actual list. The coup now is to 
only consider t that only use the ListLike interface, rather than any 
specific operations related to DList as such. That is, we will indeed 
prove that for every closed type t and t :: ListLike <5 =>■ <5 r, 

abs fDList = t [j. 

Since the polymorphism over d in the type of t is so important, we 
follow [Voigtlander| (2008a| > and make it an explicit requirement in 
a function that we will use instead of abs for switching from the 
original to the alternative representation of lists: 

improve :: (V5. ListLike <5 => 6 a) —> [a] 
improve t = abs t 

Now, when we observe the problematic runtime overhead in (|7j, 
we can replace it by 

last (improve (flatten t )). 

That this replacement does not change the semantics of the program 
is established by the following theorem, which provides the sought- 
after general correctness statement. 


Theorem 6. Let t : 

Then 

: ListLike <5 8 rfor sot 

improve t = t g . 

ne closed type r. 

Proof. We prove 


unDL foust = (f[| -H-), 

(9) 


which by the definitions of improve and abs, and by f[j -H- [] = 
tg, implies the claim. To do so, we first show that T : DList ■<=> [] 

TTZ = unDL ; ({Tl\ [7 Z]) ; (-H-) -1 

is a ListLike-acrfon, where the latter concept is defined as any 
relational action T : Ki <3- K2 for type constructors Ki and K2 
that are instances of ListLike such that 

• (empty , empty K2 ) £ V7 Z. T 7 Z, 

• (cons K1 , cons K2 ) eWTZ.TZ ->• (T 72. T 7 Z), and 

• (append K1 , append K2 ) £ V7 Z. TTZ —► (TTZ —* TTZ). 

• (emptyR, []) 6 V7 Z. T TZ, since for every TZ and (fa, fa) £ 
[TZ], (unDL emptyR fa, [] -H- fa) = (fa, fa) £ [TZ], 

• (consR, (:)) € V7 Z. TZ (F TZ T TZ), since for every TZ, 

(a, b) £ TZ, (f,bs) £ ([TZ] [71]) ; (-H-)" 1 , and (fa, fa) £ 

in 

(unDL (consR a (DL /)) fa, (b : bs) -+f fa) = 

(a : f fa,b : bs-U-fa) e [TZ] 


by (a, b) £ TZ and (/ l\,bs -H- fa) £ [7?,] (which holds due to 
(/, (bs -H-)) £ [TZ] -► [TZ] and (fa, fa) £ [TZ]), and 
• (appendR, (-H-)) 6 V7^. T TZ -» (F TZ -* T TZ), since for 
every TZ, (f, as) £ ([71] - [TZ]) ; (-H-)" 1 , (g, bs) 6 ([TZ] - 
[72.]) ; (-H-) -1 , and (fa, fa) £ [TZ], 

(unDL (appendR (DL /) (DL g)) fa, (as -tf bs) -H- fa) = 
(f (gfa),as-U-(bs-U-fa))e[TZ] 

by (/, (as -H-)) £ [TZ] [TZ], (g, (bs +)) £ [TZ] - [TZ], and 
(fa, fa) € [TZ], 

Hence, (fDList, ig) € T id T . Given that we have T id T = 
unDL ; ([id T ] ^ [id T ]) ; (-h-)” 1 = unDL ; (-H-)” 1 , this im¬ 
plies ((5). 

Note that the ListLike-action T : DList [] used in the above 
proof is the same as 

TTZ = (DList TZ) ; rep~ x , 

given that DList TZ = unDL ; ([7?.] —> [7?.]) ; DL. This connection 
suggests the following more general theorem, which can actually 
be proved much like above. 


Theorem 7. Let t :: ListLike <5 =► 5 rfor some closed type r, 
let Ki and K2 be instances of ListLike, and let h :: f ci a —> 

«• V 

• h empty K1 = empty B2 , 

• for every closed type t, a :: r, and as :: Ki T, 
h (cons K1 a as) = cons K2 a (h as), and 

•for every closed type r and as,bs :: ki t, 
h (append Kl as bs) = append K2 (h as) (h bs), 

h t K1 = t K2 . 


Theorem [6] is a special case of this theorem by setting ki = [], 
K2 = DList, and h = rep, and observing that 

• rep [] = emptyR, 

• for every closed type r, a :: r, and as :: [r], rep (a : as) = 
consR a (rep as), 

• for every closed type r and as,bs :: [r], rep (as -H- bs) = 
appendR (rep as) (rep bs), and 

• abs o rep = id, 

all of which hold by easy calculations. One key observation here 
is that the third of the above observations does actually hold, in 
contrast to its faulty “dual” ([6} considered earlier in this section. 

Of course, free theorems can now also be derived for other types 
than those considered in Theorems [6] and [7] For example, for every 
closed type t, f :: ListLike d =k 6 t —> 6 r, and h as in Theorem[7] 
we get that: 

f K2 o h = h o f K1 . 

6. Discussion and Related Work 

Of course, statements like that of Theorem [7] are not an entirely 
new revelation. That statement can be read as a typical fusion law 
for compatible morphisms between algebras over the signature de¬ 
scribed by the ListLike class declaration. (For a given r, consider 
ListLike 5 =k 5 t as the corresponding initial algebra, m t and 
K2 t as two further algebras, and the operation - Ki of instantiating 






at:: ListLike <5 => S r to a t Ki :: r as initial algebra mor¬ 

phism, or catamorphism. Then the conditions on h in Theorem [7] 
make it an algebra morphism and the theorem’s conclusion, also 
expressible as h o - K1 = - K2 , is “just” that of the standard cata¬ 
morphism fusion law.) But being able to derive such statements 
directly from the types in the language, based on its built-in ab¬ 
straction facilities, immediately as well for more complicated types 
(like ListLike 5 =$■ 5 t —> 6 t instead of ListLike 6 => 8 r), and 
all this without going through category-theoretic hoops, is new and 
unique to our approach. 

There has been quite some interest recently in enhancing the 
state of the art in reasoning about monadic programs. |Filinski and| 
|St0vri ng| < J2007j i study induction principles for effectful data types. 
These principles are used for reasoning about functions on data 
types involving specific monadic effects (rather than about func¬ 
tions that are parametric over some monad), and based on the func¬ 
tions’ defining equations (rather than based on their types only), 
and thus are orthogonal to our free theorems. But for their ex¬ 
ample applications to formal models of backtracking, Filinski and 
Stpvring also use a form of relational reasoning very close to the 
one appearing in our invocation of relational parametricity. In par¬ 
ticular, our Definition [T] corresponds to their Definition 3.3. They 
also use monad morphisms (not to be confused with their monad- 
algebra morphisms, or rigid functions, playing the key role in their 
induction principles). The scope of their relational reasoning is dif¬ 
ferent, though. They use it for establishing the observational equiv¬ 
alence of different implementations of the same monadic effect. 
This is, of course, one of the classical uses of relational parametric¬ 
ity: representation independence in different realizations of an ab¬ 
stract data type. But it is only one possible use, and our treatment of 
full polymorphism opens the door to other uses also in connection 
with monadic programs. Rather than only relating different, but se¬ 
mantically equivalent, implementations of the same monadic effect 
(as hard-wired into Filinski and Stpvring’s Definition 3.5), we ac¬ 
tually connect monads embodying different effects. These connec¬ 
tions lead to applications not previously in reach, such as our rea- 
soning about p reservation of invariants. It is worth pointing out that 
|Filinski|j2007) does use monad morphisms for “subeffecting”, but 
only for the discussion of hierarchies inside each one of two com¬ 
peting implementations of the same set of monadic effects; the rela¬ 
tional reasoning (via Monad-actions and so forth) is then orthogo¬ 
nal to these hierarchies and again can only lead to statements about 
observational equivalence of the two realizations overall, rather 
than to more nuanced statements about programs in one of them 
as such. The reason again, as with |Filinski and St0vring| ( |2007) , 
is that no full polymorphism is considered, but only parametrisa- 
tion over same-effect-monads on top-level. Interestingly, though, 
the key step in all our proofs in Section[4] namely finding a suitable 
Monad-action, can be streamlined in the spirit of Proposition 3.7 of 
|Filinski and St0vring| ( |2OO7^ or Lemmas 45, 46 of |Filinski| ( |2007) . 
It seems fair to mention that the formal accounts of Filinski and 
Stpvring are very complex, but that this is necessarily so because 
they deal with general recursion at both term and type level, while 
we have completely dodged such issues. Treating general recursion 
in a semantic framework typically involves a good deal of domain 
theory such as considered by |Birkedal et al.| ( [2007| >. We only pro¬ 
vide a very brief sketch of what interactions we expect between 
general recursion and our developments from the previous sections 
in Appendix [C] 

|S\vierstraH2008| proposes to code against modularly assembled 
free monads, where the assembling takes place by building coprod¬ 
ucts of signature functors corresponding to the term languages of 
free monads. The associated type signatures are able to convey 
some of the information captured by our approach. For example, 
a monadic type Term PutStr Int can be used to describe com¬ 


putations whose only possible side-effect is that of writing strings 
to the output. Passing a list of values of that type to a function 
/ :: Monad p =>■ [p Int] —► p Int clearly results in a value of 
type Term PutStr Int as well. Thus, if it is guaranteed (note the 
proof obligation) that “execution” of such a term value, on a kind 
of virtual machine ( [Swierstra and Altenkirch|2007l l or in the actual 
10 monad, does indeed have no other side effect than potential out¬ 
put, then one gets a statement in the spirit of our Example [6] On 
the other hand, statements like the one in our Example[8](also, say, 
reformulated for exceptions in the 10 monad) are not in reach with 
that approach alone. Moreover, Swierstra’s approach to “subeffect¬ 
ing” depends very much on syntax, essentially on term language 
inclusion along with proof obligations on the execution functions 
from terms to some semantic space. This dependence prevents di¬ 
rectly obtaining statements roughly analogous to our Examples [5] 
and[7]using his approach. Also, depending on syntactic inclusion is 
a very strong restriction indeed. For example, putStr is seman¬ 
tically equivalent to return (), and thus without visible side-effect. 
But nevertheless, any computation syntactically containing a call to 
putStr would of necessity be assigned a type in a monad Term g 
with g “containing” (with respect to Swierstra’s functor-level rela¬ 
tion : A:) the functor PutStr, even when that call’s argument would 
eventually evaluate to the empty string. Thus, such a computation 
would be banned from the input list in a statement like the one 
we give below Example [6] It is not so with our more semantical 
approach. 

Dealing more specifically with concrete monads is the topic 
of recent works by |Hutton and Fulgerj (|2008|>, u sing point-free 
equational reasoning, and by |Nanevski et al.H2008) , employing an 
axiomatic extension of dependent type theory. 

On the tool side, we already mentioned the free theorems gener¬ 
ator at http://linux.tcs.inf.tu-dresden.de/~voigt/ft/ 
It deals gracefully with ordinary type classes (in the offline, shell- 
based version even with user-defined ones), but has not yet been 
extended for type constructor classes. There is also another free 
theorems generator, written by Andrew Bromage, running in 
Lambdabot (http: //haskell. org/haskellwiki/Lambdabot I. 
It does not know about type or type constructor classes, but 
deals with type constructors by treating them as fixed functors. 
Thus, it can, for example, derive the statement {3} for functions 
f K :: [k a] —> k [a], but not more general and more interesting 
statements like those given in Theorem [3] and earlier, connecting 
different Monad instances, concerning the beyond-functor aspects 
of monads, or our results about ListLike. 
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A. Proof of Theorem [l] 

We prove that for every l' :: [Int], 

f* (map return* l') = return,,, (unld (/id (map Id l'))), 

newtype Id a = Id {unld :: a } 

instance Monad Id where 

return a = Id a 
\da»=k = ka 

To do so, we first show that T : k 44 Id with 

T1Z = return -1 ; 1Z ; Id , 

where is (forward) relation composition and “ -1 ” gives the 
inverse of a function graph, is a Monad-action. Indeed, 

• (return*, return id) £ V72. 72 —> T 72, since for every 7 Z and 
(a, b) £ 7 Z, (return* a, returns b) m ( return K a, Id b) £ 
return -1 ; 72. ; Id, and 

. ((»=„), (»=i d )) G V72. VS. T TZ -» ((72 -► T S) -> 
T S), since for every 72, S, (a, b) G 72, and (ki, fa) G 72 —> 
T S, (return* a iS>=* ki. Id b »=id fa) = (fa a, fa b) G 
T S. (Note the use of monad law {TJ for k.) 

Hence, by what we derived towards the end of Section[3] (}*, /id) G 
[T wfint] —> F id\ nt . Given that we have T id\ nt = return* 1 ; Id = 
(return* ° unld) -1 , this implies the claim. 

B. Proof of Theorem |2] 

We prove that for every l :: [k Int], 

P (f K l) — unld (/id (map (Id o p) l )), 
where the type constructor Id and its Monad instance definition 
are as in the proof of Theorem [I] To do so, we first show that 
T : k 44- Id with 

TlZ=p -, 72 ; Id 
is a Monad-action. Indeed, 

• (return*, return id) G V72. 72 —► T 72, since for every 72 and 
(a, b ) G 72, (return* a,b ) G p ; 72 by p (return* a) = a, and 

. ((»=„), (»=i d )) G V72. VS. T 72 -► ((72 -► T S) -> 
T S ), since for every 72, S, (m, b) G p ; 72, and (fa, fa) G 
72 —> T S, (m :?>=«; fa, Id b »=id fa) G p ; S ; Id by 
p (m »=« fa) = p (fa (p m)) and (fa (p m),fa b) G 
p ; S ; Id (which holds due to (fa, fa) G 72 —► T S and 
(p m, b) G 72). 

Hence, (f*, /id) G [!F idi„ t ] —> T idi n t- Given that we have 
T idint = P ld = ldop=p; unld -1 , this implies the claim. 

C. Free Theorems, the Ugly Truth 

Free theorems as described in Section [2] are beautiful. And very 
nice. Almost too good to be true. And actually they are not. At least 
not unrestricted and in a setting more closely resembling a modem 


functional language than the plain polymorphic lambda-calculus 
for which relational parametricity was originally conceived. In par¬ 
ticular, problems are caused by general recursion with its poten¬ 
tial for nontermination. We have purposefully ignored this issue 
throughout the main body of the paper, so as to be able to explain 
our ideas and new abstractions in the most basic surrounding. In 
a sense, our reasoning has been “up to _L”, or “fast and loose, but 
morally correct” ( |Danielsson et al.||2006^ . We leave a full formal 
treatment of free theorems involving type constructor classes in the 
presence of partiality as a challenge for future work, but use this 
appendix to outline some refinements that are expected to play a 
central role in such a formalisation. 

So what is the problem with potential nontermination? Let us 
first discuss this question based on the simple example 

/ :: IN - M 

from Section[2] There, we argued that the output list of any such / 
can only ever contain elements from the input list. But this claim 
is not true anymore now, because / might just as well choose, for 
some element position of its output list, to start an arbitrary looping 
computation. That is, while / certainly (and still) cannot possibly 
make up new elements of any concrete type to put into the output, 
such as 42 or True, it may very well put _L there, even while not 
knowing the element type of the lists it operates over, because _L 
does exist at every type. So the erstwhile claim that for any input 
list l the output list / l consists solely of elements from l has to be 
refined as follows. 

For any input list l the (potentially partial or infinite) output 
list f l consists solely of elements from l and/or _L. 

The decisions about which elements from l to propagate to the 
output list, in which order and multiplicity, and where to put _L can 
again only be made based on the input list l, and only by inspecting 
its length (or running into an undefined tail or an infinite list). 

So for any pair of lists l and l' of same length (refining this 
notion to take partial and infinite lists into account) the lists 
f l and / l' are formed by making the same position-wise 
selections of elements from l and l', respectively, and by 
inserting _L at the same positions, if any. 

For any 1/ = map g l, we then still have that f l and / l ' are of 
the same length and contain position-wise exactly corresponding 
elements from l and l' = map g l, at those positions where f 
takes over elements from its input rather than inserting _L. For those 
positions where f does insert _L, which will then happen equally for 
/ l and / l 1 , we may only argue that the element in / l 1 contains 
the p-image of the corresponding element in / (if indeed _L is the 
g-image of _L, that is, if g is a strict function. 

So for any list l and, importantly, strict function g, we have 
/ (map g l) = map g (f l). 

The formal counterpart to the extra care exercised above regarding 
potential occurrences of _L is the provision of |Wadler| j 1989| Sec¬ 
tion 7) that only strict and continuous relations should be allowed 
as interpretations for types. 

In particular, when interpreting quantification over type vari¬ 
ables by quantification over relation variables, those quantified re¬ 
lations are required to contain the pair (_L, _L), also signified via 
the added ■ in the new notation TZ : Ti <X T2- With straight¬ 
forward changes to the required constructions on relations, such 
as explicitly including the pair (_L,_L) in [72] : [n] 44> [72] and 
Maybe 72 : Maybe n Maybe T2, and replacing the least by 
the greatest fixpoint in the definition of [72.], we get a treatment of 
free theorems that is sound even for a language including general 
recursion, and thus nontermination. 


For the extension to the setting with type constructor classes 
(cf. Section[3]l, we will need to mandate that any relational action, 
now denoted T : Ki K2, must preserve strictness, i.e., map 
72 : Ti T2 to T TZ : sq Ti K2 T2- Apart from that, 
Definition[T| for example, is expected to remain unchanged (except 
that 72 and o will now range over strict relations, of course). 

Under these assumptions, we can investigate the impact of the 
presence of general recursion on the results seen in the main body 
of this paper. Consider Theorem [T] for example. In order to have 
T : k Id in its proof, we need to change the definition of T TZ 
as follows: 

T TZ = {(-U,J|} U (return,- 1 ; 72 ; Id). 

For this relational action to be a Monad-action, we would need the 
additional condition that X »= K fci = fci _L for any choice of hi. 
Then, (/«,/«) € [P idint] —> P idi„t would allow to derive the 
following variant, valid in the presence of general recursion and _L. 


Theorem 1’. Let f :: Monad p =>■ [p Int] —> p Int, let k be 
an instance of Monad satisfying law ijTji and _L »= K k = 
k _L for every (type-appropriate) k, and let l :: [k Int]. If 
every element in l is a return K -image or X, then so is f K l. 


Note that the Reader monad, for example, satisfies the conditions 
for applying the thus adapted theorem. 

Similar repairs are conceivable for the other statements we have 
derived, or one might want to derive. Just as another sample, we 
expect Example [7] to change as follows. 


Example 7’. Let / :: Monad p => [p Int] —> p Int, let r be 
a closed type, and let l :: [State t Int]. If for every element 
State g in l, the property P(g) defined as 

P(g) := Vs. snd (g s) = s V snd (g s) = X 
holds, then also / l is of the form State g for some g with 
P(9). 


Note that even if we had kept the stronger precondition that 
snd o g = id for every element State g in l, it would be im¬ 
possible to prove snd o g = id instead of the weaker P(g) for 
/ l = State g. Just consider the case that / invokes an immedi¬ 
ately looping computation, i.e., f l = X = State J-j^The g = X 
here satisfies P(g), but not snd o g = id. 


8 The equality ± = State J_ holds by the semantics of newtype in 
Haskell. 







